There are standardized solution for MDT data collection as specified, for instance, in 3rd Generation Partnership Project Technical Specification (3GPP TS) 32.422 and related specifications in a cellular system, which has a management architecture as described in FIG. 1 (which is an excerpt from 3GPP TS 32.101). MDT is also specified for Universal Mobile Telecommunications System (UMTS) and Long Term Evolution (LTE) systems in 3GPP.
FIG. 1 shows an example management architecture for MDT data collection. Accordingly, as shown in FIG. 1, the architecture comprises a network 100, which in turn comprises organizations A and B, of which only organization A is exemplified. Boxes denote functional entities (such as “Enterprise Systems”), and numerals 1 to 6 on the connections drawn between the boxes denote interfaces between the functional entities.
Data collection for MDT function is, for instance, ordered via the Itf-N (interface numeral 2 in FIG. 1) from a Network Manager (NM) 1002 to a Domain Manager 1001a /Element Manager 1001b (DM/EM), which in turn orders a Network Element (NE) 1001 to perform the MDT data collection according to the request originating from the NM 1002. The MDT data collection can be ordered from the NM 1002 using the trace functionality as specified, for instance, in TS 32.422. The MDT data collection can be ordered for a specific subscriber or terminal, identified by the International Mobile Subscriber Identity/International Mobile Equipment Identity (IMSI/IMEI) (also called signaling based MDT trace) or for a specific area, i.e., set of cells (also called area based MDT or management based trace).
As some pieces of the data collected during an MDT session may be sensitive from a privacy point of view, a user consent indicator is configured per subscriber in the Home Subscriber Server (HSS) or Home Location Register (HLR). The user consent indicator is propagated in the signaling control chain (interface 6 in FIG. 1) to the NE 1001 (in case of signaling-based MDT trace) or via the management interface from DM 1001a to the NE (interface 1 in FIG. 1) (in case of management-based MDT). The NE 1001 carries out the selection of UEs (not shown) that should participate in the MDT data collection.
When a MDT data collection order (trace order configuration) is received in the NE 1001, NE 1001 checks for sessions that fulfill the criteria from the MDT order. When such a session is found, the NE 1001 checks the user consent indicator for that session. Only if the user consent is set to that MDT collection being allowed, the NE 1001 starts the MDT data collection for that session.
There are different types of MDT:    1. Area-based MDT: The MDT order is for a specified area typically for a cell or list of cells.    2. Signaling-based MDT: The MDT order is for a specified user (IMSI) or User Equipment (UE identified by IMEI).    3. Logged MDT: The MDT data collection is performed for UEs that are in idle mode.    4. Immediate MDT: The MDT data collection is performed for UEs that are in active mode.
The types 1 and 2 as well as 3 and 4 are mutually exclusive, while types 1 and 2 are combinable with 3 or 4.
Accordingly, the standard depicted above defines different trace job types depending on whether immediate or logged MDT measurements are requested, with combination of regular trace, etc. The current values of the traceJob type as follows (see TS 32.422 for the jobType parameter).
The jobType is a conditional mandatory parameter. The condition is either MDT or Radio Link Failure (RLF) data collection functionality being supported. It defines whether a single trace job, a combined MDT and trace job or RLF report collection job is activated. This parameter also defines the MDT mode. The jobType parameter is an Enumerated type with the following values:                Immediate MDT only (0);        Logged MDT only (1);        Trace only (2);        Immediate MDT and Trace (3);        RLF reports only (4).NOTE: The jobType “RLF reports only” is applicable only in management-based trace activation in Evolved UMTS Terrestrial Radio Access Network (E-UTRAN).        
The standard also defines PM measurements, which are measurements aggregated to cell level and thereby used to denote the overall cell level performance, instead of the individual UE level performance as in the case of MDT data, see for instance TS 32.425 for E-UTRAN PM measurements and 32.405 for UTRAN measurements and TS 32.401 for the overall concept and requirements for PM measurements.
The PM measurements are produced by the Network Elements (NE) 1001 and are collected by the Element Manager (EM) and finally transferred via the standardized Itf-N interface (see FIG. 1). The standard defines a variety of PM measurements, including such as success rate of connection setups, radio bearer setups or average cell throughput, utilization, etc.
In all cases, the PM measurements are produced by aggregation of individual measurement samples, where there is a given set of aggregation “functions” defined in the standard (e.g., cumulative, gauge, etc.).
Existing Problems Not Realized by the Prior Art
In current 3GPP networks (such as UMTS or LTE), there is possibility for an Operation and Maintenance (OAM) system to collect MDT measurements from UEs and from the network for network observation and optimization purposes. The MDT measurements are collected via the trace mechanism and are stored in the trace files, which are transferred from the network to a Trace Collection Entity (TCE). The amount of MDT data in the trace files can be significant, requiring large storage and processing resources. Moreover, for some use cases, the MDT data might be unnecessarily detailed. Therefore, there is a need to support the aggregated reporting of MDT data in terms of PM measurements (e.g., PM counters).
The current MDT trace mechanism supports the collection of MDT measurements in trace format only, i.e., where all individual samples are collected. For some use cases, this may represent an overwhelming amount of data, which may anyway be aggregated in the OAM system for the particular use case. That is, transferring all the detailed MDT data from the NE 1001 to OAM system may be unnecessary in those cases. On the other hand, there exist PM measurements (counters), which collect measurements in an aggregated way and MDT measurement samples would be a useful input for a number of new PM measurements. However, defining only new PM measurements would not be sufficient alone, as no mechanisms exist that would configure and trigger the required measurements at UEs (e.g., MDT measurements) and thereby no measurement samples would be produced for the PM counters.